Document processing facilities often use document processing systems such as inserters to assemble and insert mail into envelopes, sorters to sort mail and other high speed document processing equipment. The speed of such equipment is generally measured by the number of mail pieces that can be produced during a given time or job run. Hence, to maximize the efficiency of the document processing system during a job run, it is vital that any errors be minimized if not completely eliminated. Typical errors that may occur during a job run may include a sequence number error, document spoilage (e.g., document bent, wrinkled, or torn) and other such errors that relate to the specific processing requirements and needs of the user of the document processing system. For addressing these errors, two commonplace reconciliation methodologies—real-time error reconciliation and post-job error reconciliation—are often employed.
The first methodology, real-time error reconciliation, results in complete cessation of a job run upon the detection of an error. So, for instance, if a sequence error is detected during the job run, the system is completely stopped until the problem is rectified by the operator of the inserter. The benefit to this methodology is that all errors must be handled in order for the job run to be fully completed; no further error resolutions need be performed at the end of a job run. However, this benefit is outweighed by the obvious fact that the more errors that occur during a particular job run, the more inefficient the machine. This inefficiency problem is magnified even further for very high-speed inserters, where one or more incremental periods of machine stoppage translate into incredible reductions in machine productivity. Moreover, the constant halting of high-speed electromechanical systems such as an inserter can lead to further complications (short-term or long-term) such as paper jams, lubrication issues, mechanical failures and other breakdowns common to devices subject to constant stop-and-go conditions.
Post job error reconciliation, unlike real-time reconciliation allows for the partial completion of a job run (assuming no machine stop errors were invoked). The job run is partial because as long as there are errors detected with various mail pieces, the integrity of the job run cannot be assumed, and is therefore not complete. In post job reconciliation, a log file of errors is maintained as they occur during the job run and made available to the operator after the processing of the last mail piece. The operator then utilizes the error log to determine which pieces are in error and require reconciliation. So, in the case of a missing piece or a sequence error, the operator can then identify what occurred with the missing pieces, whether they were hand stuffed, diverted to another production line, etc.
While post-job error reconciliation can make for somewhat better machine efficiency, the mail job cannot be released until all of the error pieces have been resolved. One can imagine how troubling this can be for a mail production facility, particularly in situations where a particular job must be completed and placed in the mail according to a specific deadline. With post job error reconciliation, the task of reconciling that was performed throughout the real-time reconciliation process is now deferred to the backend. As a further complication, because the errors are not addressed until the end of a job run, errors capable of affecting the integrity of all other mail pieces cannot be detected early on (e.g., when improper indicia being applied to one mail piece affects all subsequent mail pieces). This could potentially result in entire mail production runs having to be redone—negatively impacting both work and cost efficiency.
In FIGS. 1 and 2, prior art means of reconciling errors as they occur during the execution of a job run are shown. Specifically, FIG. 1 illustrates the process of real-time error reconciliation, wherein errors are required to be handled as they occur. According to this arrangement, error settings and/or event settings are established by the operator of the document processing system (step 302). Such settings act as triggers which indicate to the document processing system the types of errors or tolerances (e.g., error or event sensitivity levels) it should recognize during the job run. When the document processing system has documents still requiring production (event 304), the documents are processed (event 306) as long as no errors (event 308) corresponding to the one or more error or event settings established during event 302 are detected. As a job run is executed, production run data (e.g., mail piece, mail count, corresponding sequence number, etc.) may be saved to a log file throughout the execution of the job run (event 310) for subsequent report generation or inspection by the operator.
In instances where errors are detected during the execution of the system (event 312), real-time error reconciliation calls for the document processing system to be completely stopped (event 314). As such, no further processing of documents or mail pieces may commence. When this occurs, the error requiring reconciliation is presented to the operator (event 316) along with various options that the operator may employ to reconcile the error (event 318). The errors may be ascertained by the operator in various ways such as by perusal of the production run log data, or by means of a graphical user interface presented by a control computer system 124 operating in connection with the document processing system 100. Likewise, the reconciliation options may also be determined by the operator manually (e.g., inspection of an error log) or by means of a graphical user interface. Regardless of how the error and reconciliation information is presented and/or determined, the job run is not restarted until the error is handled (event 320). Obviously, such a process can become quite daunting and time consuming as greater numbers of errors occur. Numerous situations, such as the removal of a mailpiece due to jam damage, can result in a sequence error being detected shortly after the machine is restart, resulting in yet another stoppage. Ultimately, an increased number of machine stops diminishes the efficiency and throughput capacity of the system.
FIG. 2 illustrates the process of post-job error reconciliation. As in real-time error reconciliation, error and/or event settings are established (event 402) to allow the document processing system to perceive errors and detect events requiring reconciliation. The document processing system is executed as usual for as long as there are mail pieces requiring processing (events 404 and 406). Unlike real-time error reconciliation, when an error is detected according to the post-job error reconciliation process (event 408), the document processing system is not stopped. The errors may optionally be recorded to a log file for subsequent review by the operator of the document processing system (event 410). When the last mail piece of the job run is processed, any erroneous mail pieces requiring reconciliation are presented to the operator (event 412) along with any reconciliation options (event 414). Once the errors are reconciled (event 416), this signifies the completion of the job run.
The error correction process for the post-job error reconciliation process is deferred until the last mail piece for the production run is processed as opposed to errors being handled as they occur. While this process may increase the overall work efficiency of the system, cost efficiency could be compromised due to the cumulative effects of erroneous mail pieces affecting the integrity of the entire mail run. Most of the mail produced during the job must be staged in the production area since corrects to the mail trays will be required.
To address these issues, a need has arisen to increase the throughput of mail processing machines by limiting the number of document processing system stops while effectively allowing errors to be reconciled during the continued operation of the system.